iProcurement, which is available from Oracle Corporation of Redwood Shores, Calif. is a self-service requisitioning software product that when executed in a computer enables an organization (such as an automobile manufacturer) to use computers to monitor and control spending by its employees. A computer which executes iProcurement enables employees to create, manage, and track their own orders for goods and services (“items”) needed by the organization over a communications network (e.g. Internet), while the organization's purchasing department retains central control. In iProcurement, securing attributes, called realms can be set up to restrict a user's access to items identified in a catalog—either by item categories, or by punchout supplier sites. For details on securing attributes of iProcurement see pages 2-43, 3-64 to 3-73 of Oracle® iProcurement Implementation Guide, Release 11i, Part No. A85361-04, published August 2003, incorporated by reference herein as background.
Another example of prior art technology is row level security as implemented in a software product of the type shown in FIGS. 1A-1E and discussed next. Specifically, certain prior art computers known to the current inventors execute instructions to display a user interface (FIG. 1 A) that enables a human administrator to specify a type of security to be applied when any product in a product line, such as Peoplesoft Financials, available from Oracle Corporation, is used by other humans who are non-administrators, i.e. users. As shown in FIG. 1A, an administrator may specify that there are to be no security restrictions at all, resulting in every user of the product being allowed access to every screen in the product.
Alternatively, security may be enforced in the just-described Peoplesoft product based on an identifier of each individual user (shown as “User ID Level Security” in FIG. 1A) or based on a permission list (shown in FIG. 1A as “Permission List Level Security”). When either User ID Level Security or Permission List Level Security is selected by an administrator, a set of fields that can be secured during normal use of the product is presented to the administrator as shown in the bottom half of the screen in FIG. 1A (labeled “Secured Fields”). Prior art fields that can be secured are (a) Business Unit which represents an organization unit (comparable to a Set of Books in the E-Business Suite product line available from Oracle Corporation), (b) Setid which is a mechanism that controls groups of values for accounting codes called Chartfields, (c) Ledger which identifies specific accounting ledgers that may be accessed, (d) Book which represents a slice of accounting activity within a ledger, (e) Pay Cycle which refers to groups of vouchers or invoices scheduled for payment, and (f) Project which is typically identified by a unique project number, with a secondary option to define the project names/numbers by use of a list or a tree, already existing in the computer, as shown in the drop-down box.
FIG. 1B demonstrates an example of how a user's access to information related to various Business Units (FIG. 1A) is initially defined by the administrator, for all products in the Peoplesoft Financials product line. FIG. 1C shows an example setup, to allow a user named “VP1” access to a ledger named CC_FS_EXP. FIG. 1D is an example of how security for projects is set up when the option selected in the Security Options page is “Use tree”. The selected projects displayed by the prior art computer to a user are the ones that are authorized for that user (e.g. VP1) when that user is assigned the role of Project Manager by an administrator. Once values have been defined and assigned to a user, a process needs to be executed by the computer, to build an appropriate dynamic view (FIG. 1E).
The just-described views (FIG. 1E) are used by multiple products in Peoplesoft Financials to restrict access to certain sets of data, based on security options defined by the administrator, e.g. on a Business Unit, Ledger or Project. Use of these views in the prior art (FIG. 1E) is by all products to internally secure data in such a way that when a user is logged in and using a product, search views used for prompting the user display only authorized values based on security options that were specified in common (FIG. 1B) for all products in the product line. In the example shown in FIG. 1B, a list of values that will be presented to user VP1 for selection in any product in Peoplesoft Financials only contains prompt values BUY01, BUY02, BUY03, BUY04, BUY05, BUY06, BUY07, BUY08 and US001 which the administrator has selected. Accordingly, in all products in Peoplesoft Financials, user VP1 is not able to view the prompt value of any other business unit (e.g. US002), and hence unable to select to view data for such other business unit. Similar behavior can be implemented using common security options, e.g. a Ledger defined for the user, as well as for Projects.
The current inventors note that certain prior art of the type illustrated in FIGS. 1A-1E does not permit securing a user's access to a parameter value differently in different components. For example, an accounts payable (AP) clerk may need access to all accounts and to all departments of an organization in one component, to enter an organization's vendor invoices. The current inventors note that if options are set up for the AP clerk to be granted access to all accounts and all departments, the only way to do so in the prior art known to the inventors automatically grants access in all components. On doing so in prior art software, the current inventors note that the AP clerk is automatically given the ability to place an order for any item in any account, and to charge it to any department, which is a breach in security. Hence, the current inventors believe there is need for improvement, of the type discussed below.